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Response to Amendment 

1 . This action is responsive to the amendment filed on December 28, 2004. Claims 
1-11 are amended. Claims 12-19 are added. Claims 1-19 represent an application, 
system and software for a "Multi-platform Application." 

Response to Arguments 

2. In the remarks, applicant argues that "Kraslavsky fails to teach or suggest a table 
for storing a plurality of IPX/SPX network segment addresses and the number of hops 
each segment is from the computer accessing said table." The applicant further stated 
that the "Office erroneously attempts to equate this feature with the table of entry points 
into various service routines provided by the LSL in Kraslavsky." The applicant cited 
numerous columns and line numbers pointing to different facets of the Kraslavsky's 
invention in an attempt to distinguish the invention under examination with Kraslavsky's 
invention; for example applicant cited col. 2, lines 35-48 for the proposition that the 
invention in Kraslavsky deals with dynamically reconfiguring frame type assignments 
and protocol stacks for a network device from a remote device. 

Kraslavsky reads as follows in col. 2, lines 35-48: 

Accordingly, a way is needed to remotely reconfigure the frame type 
assignments and the loaded protocol stacks for a peripheral, and the 
reconfiguration must be possible regardless of the protocol and frame type 
currently in use by the device from which the reconfiguration is performed 

SUMMARY OF THE INVENTION 
These needs are addressed by the present invention, in which the protocol 
stacks loaded in a network device and/or the frame type assigned to each loaded 
protocol stack can be dynamically reconfigured from a remote device regardless 
of the protocol used by the remote device. 

The Examiner submits that contrary to applicant's assertions Kraslavsky teaches 
a network interface device which can communicate with other devices via a local area 
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network using various protocols and frame types and which can be remotely 
reconfigured to use different protocols and frame types. (See abstract) 

As for the argument that Kraslavsky fails to teach or suggest a table for storing a 
plurality of IPX/SPX network segment addresses and the number of hops each segment 
is from the computer accessing said table, applicant is directed to col. 8, lines 13-27 
wherein Kraslavsky discloses the Link Support Layer (LSL) as a multiplexer software 
module which multiplexes between MLID and the protocol stack modules. An IPX 
protocol stack module for supporting IPX/SPX protocol stack module is also provided. 
An artisan of ordinary skill in the art would know that a multiplexing function tacitly 
encompasses a table. Kraslavsky may not specifically disclose the number of hops 
each segment is from the computer accessing the table. However, Rune discloses this 
concept at col. 4, lines 37-43 as outlined in the First Office Action, which articulated a 
prima facie case of obviousness rejecting the claims under examination. 

Furthermore, in response to applicant's arguments against the reference 
individually, one cannot show nonobviousness by attacking references individually 
where the rejections are based on combinations of references. See In re Keller, 642 
F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 
USPQ 375 (Fed. Cir. 1986). 

3. Applicant next argued that Kraslavsky fails to teach or suggest IPX/SPX Routing 
Information Protocol (RIP) request packet sending means adapted to transmit an RIP 
request packet across an IPX/SPX network. Moreover, applicant asserted that (a) 
Kraslavsky fails to teach or suggest IPX/SPX Routing Information Protocol (RIP) 
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response packet receiving means adapted to receive RIP response packets in response 
to the RIP request packet; (b) Kraslavsky never teaches or suggests transmitting an 
application defined packet to network segments. 

As stated above, Kraslavsky may not specifically disclose these specific 
limitations as claimed. However, Rune unequivocally discloses this concept at col. 4, 
lines 37-43 (also see Fig. 4, 5, 7, 8, 9, 10) as outlined in the First Office Action, which 
articulated a prima facie case of obviousness rejecting the claims under examination. 

The test for obviousness is not whether the claimed invention is expressly 
suggested in any one or all of the references. Rather, the test is what the combined 
teachings of the references would have suggested to those of ordinary skill in the art. 
See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

4. Applicant alleged that there is no motivation to combine the references. This 
assertion was followed by a recitation of what applicant purports are the teachings of 
Kraslavsky. However, applicant unwittingly admits that Rune covers a method to store 
in a table the addresses of homologous servers and to provide to the requesting client 
one of the servers that is selected using a "shorter distance" concept in a TCP/IP 
network , (page 1 5 of 1 6) 

In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
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the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case the motivation 
articulated in the First Office Action is found in the secondary reference. (See Rune col. 
1, lines 43-51.) 

5. As to claim 12, it is now being presented for examination; applicant is invited to 
peruse the rejection that follows. 

6. Applicant's arguments have thus been fully considered but they are not 
persuasive. In response to Applicant's arguments, 37 CFR § 1.1 1 1(c) requires applicant 
to "clearly point out the patentable novelty which he or she thinks the claims present in 
view of the state of the art disclosed by the references cited or the objections made. 

7. The claims save the newly added ones namely claims 12-19 stand rejected as 
articulated in the First Office Action (see below) and all objections not addressed in 
Applicant's response are herein reiterated. 
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Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived 
by the manner in which the invention was made. 

8. Claims 1, 3-4 are rejected under 35 U.S.C. 5103(a) as being unpatentable over 
Kraslavskv (US 5,699.350) in view of Rune (US 6.304.913.) 

Kraslavsky teaches the invention substantially as claimed including a network 
interface device which can communicate with other devices via a local area network 
(LAN) using various protocols and frame types, and which can be remotely reconfigured 
to use different protocols and frame types. (See abstract). 
Claim 1 : 

Referring to claim 1 , Kraslavsky teaches an application operable on a computer 
adapted to communicate using at least an IPX/SPX protocol, said application 
comprising: ( See Fig. 9(a). 9(b), (9c), 9(d) (182 )). 

means for accessing a table for storing a plurality of IPX/SPX network segment 
addresses and the number of hops each segment is from the computer accessing said 
table; ( See col. 14. lines 48-53 .) 

IPX/SPX Routing Information Protocol (RIP) request packet sending means 
adapted to transmit an RIP request packet across an IPX/SPX network; ( See col. 13. 
lines 1-27; col. 14. lines 37-47 ). 

IPX/SPX Routing Information Protocol (RIP) response packet receiving means 
adapted to receive RIP response packets from within a pre-determined number of 
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network hops and to store the network segment addresses and the number of hops 
each segment is from the computer contained in said RIP response packets in said 
table; ( See col. 11. lines 11-48 ). 

IPX/SPX broadcast means responsive to an application request to transmit an 
application defined packet to network segments within a pre-determined number of 
hops stored in said table. ( See col. 13, lines 51-57 ). 

Kraslavsky teaches an application operable on a computer adapted to 
communicate using at least an IPX/SPX protocol. Kraslavsky fails to specifically teach 
receiving RIP response packets from within a specific number of network hops. 
However, Rune teaches this concept extensively. ( See Fig. 4, 5, 7, 8, 9, 10 and col. 4, 
lines 37-43 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the hop count system disclosed by Rune. Such a system would improve efficiency of 
the network. Therefore, claim 1 is rejected. 
Claim 3 : 

Referring to claim 3, Kraslavsky substantially teaches the invention including an 
application according to claim 2 wherein said IPX/SPX Routing Information Protocol 
(RIP) request packet sending means is responsive to a domain name server (DNS) 
response indicating failure to locate a web server corresponding to a uniform resource 
locator (URL), to transmit said RIP request packet across an IPX/SPX network. 

Kraslavsky teaches a communication system that uses various protocols and 
frame types (See above). Kraslavsky does not specifically teach a response from a 



Application/Control Number: 09/887,499 Page 8 

Art Unit: 2157 

DNS server indicating failure. However, Rune specifically discloses a DNS server failing 
to locate a host. (See col. 5, lines 27-38). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the DNS server disclosed by Rune. Such a system would provide efficacy to the 
network. Therefore, claim 3 is rejected. 
Claim 4 : 

Referring to claim 4, Kraslavsky substantially teaches the invention including an 
application according to claim 2 wherein said IPX/SPX Routing Information Protocol 
(RIP) request packet sending means is adapted to periodically transmit said RIP 
request packet across an IPX/SPX network. ( See col. 11, line 49 - col. 1 2, line 37 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to use the communication system taught by Kraslavsky. 
Therefore, claim 4 is rejected. 
Claim 6 : 

Referring to claim 6, Kraslavsky substantially teaches the invention including an 
application as claimed in claim 5 wherein said application is adapted to communicate 
using a TCP/IP protocol and further comprising: means, responsive to no reply being 
received for said name request, for transmitting a TCP/IP name request for a TCP/IP 
server providing said service. 

Kraslavsky teaches means for causing an IPX/SPX broadcast and 
communication using TCP/IP protocol. ( See col. 11 f lines 11-26: col. 13. lines 1-6, 28- 
50). Kraslavsky does not specifically disclose response to a domain name server (DNS) 
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response indicating failure to locate a web server corresponding to a uniform resource 
locator (URL). However, Rune specifically discloses a DNS server failing to locate a 
host. (See col. 5, lines 27-38 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the DNS server disclosed by Rune. Such a system would provide efficacy to the 
network. Therefore, claim 6 is rejected. 
Claim 7 

An application as claimed in claim 1 wherein said computer is a multi-platform 
router also adapted to communicate using a TCP/IP protocol, said router comprising: 
means, responsive to a domain name server (DNS) response for a client indicating 
failure to locate a web server corresponding to a uniform resource locator (URL) 
required at said client, for causing said IPX/SPX broadcast means to transmit a name 
request for an IPX/SPX server providing a service corresponding to said URL; and 
means, responsive to receipt of a response to said name request containing an 
IPX/SPX address of an IPX/SPX server, for relaying said address to said client enabling 
peer-to-peer communication between said client and said IPX/SPX server. 

Kraslavsky teaches means for causing an IPX/SPX broadcast and 
communication using TCP/IP protocol. ( See col. 11, lines 11-26: col. 13, lines 1-6. 28- 
50 ). Kraslavsky does not specifically disclose response to a domain name server (DNS) 
response indicating failure to locate a web server corresponding to a uniform resource 
locator (URL). However, Rune specifically discloses a DNS server failing to locate a 
host. ( See col. 5. lines 27-56 ). 
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Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the DNS server disclosed by Rune. Such a system would provide efficacy to the 
network. 
Claim 8 : 

An application as claimed in claim 1 wherein said computer is a multi-platform 
router also adapted to communicate using a TCP/IP protocol, said router comprising: 
means, responsive to a domain name server (DNS) request from a client, for causing 
said IPX/SPX broadcast means to transmit a name request for an IPX/SPX server 
providing a service corresponding to said URL; and means, responsive to receipt of a 
response to said name request containing an IPX/SPX address of an IPX/SPX server, 
for relaying said address to said client enabling peer-to-peer communication between 
said client and said IPX/SPX server. 

Kraslavsky teaches means for causing an IPX/SPX broadcast and 
communication using TCP/IP protocol. ( See col. 11, lines 11-26: col. 13, lines 1-6, 28- 
50). Kraslavsky does not specifically disclose response to a domain name server (DNS) 
response indicating failure to locate a web server corresponding to a uniform resource 
locator (URL). However, Rune specifically discloses a DNS server failing to locate a 
host. ( See col. 5, lines 27-56 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the DNS server disclosed by Rune. Such a system would provide efficacy to the 
network. 
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Claim 9: 

A multi-platform application as claimed in claim 1 wherein said computer is a 
server. (See col. 1 1 , lines 49-64.) Hence, it would have been obvious at the time of the 
invention for an artisan of ordinary skill in the art to use the communication system 
taught by Kraslavsky. 
Claim 10 : 

A computer program product comprising computer program code stored on a 
computer readable storage medium for, when executed on a computing device, 
communicating using at least an IPX/SPX protocol, the program code comprising the 
application of claim 1. (See claim 1 rejection above.) 
Claim 11 : 

In a computer connected to a network, a method for communicating using at 
least an IPX/SPX protocol, comprising the steps of: 

transmitting a Routing Information Protocol (RIP) request packet across an 
IPX/SPX network; ( See col. 13, lines 1-27: col. 14, lines 37-47 .) 

receiving one or more RIP response packets from within a pre-determined 
number of network hops; 

storing in a table a plurality of IPX/SPX network segment addresses and the 
number of hops each segment is from the computer accessing said table contained in 
said RIP response packets; and ( See col. 14, lines 48-53 .) 

responsive to an application request, transmitting an application defined packet 
to network segments within a pre-determined number of hops stored in said table.( See 
col. 13, lines 51-57 .) 
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9. Claim 2 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kraslavskv 
(US 5,699.350) in view of Rune (US 6.304,913) in further view of Ogus (U.S. 6,587,875) 
and further in view of Spence et al. (US 6.185.600). 
Claim 2 : 

Referring to claim 2, Kraslavsky substantially teaches the invention including an 
application according to claim 1 wherein said application is a multi-platform Internet 
browser adapted to communicate using a TCP/IP protocol and further comprising: 

means, responsive to a domain name server (DNS) response indicating failure to 
locate a web server corresponding to a uniform resource locator (URL), for causing said 
IPX/SPX broadcast means to transmit a name request for an IPX/SPX server providing a 
service corresponding to said URL; and 

means, responsive to receipt of a response to said name request containing an 
IPX/SPX address of an IPX/SPX server, for relaying said address to said application 
enabling peer-to-peer communication between said application and said IPX/SPX server. 

Kraslavsky teaches means for causing an IPX/SPX broadcast and communication 
using TCP/IP protocol. ( See col. 11. lines 11-26: col. 13. lines 1-6. 28-50 ). Kraslavsky 
does not specifically disclose response to a domain name server (DNS) response 
indicating failure to locate a web server corresponding to a uniform resource locator (URL). 
However, Rune specifically discloses a DNS server failing to locate a host. ( See col. 5. 
lines 27-38 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
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the DNS server disclosed by Rune. Such a system would provide efficacy to the 
network. 

Neither Kraslavsky nor Rune discloses peer-to-peer communication. However, 
Ogus teaches peer-to-peer communication at col. 3, line 66 - col.4, line 6). Hence, it 
would have been obvious at the time of the invention for an artisan of ordinary skill in 
the art to combine the communication system taught by Kraslavsky and the DNS server 
disclosed by Rune with the peer-to-peer communication disclosed by Ogus . Such a 
system would provide flexibility to the network. 

Neither Kraslavsky and Rune nor Ogus discloses multi-platform Internet browser 
adapted to communicate using a TCP/IP protocol. However, Spence teaches a 
universal event browser by providing a single front-end universal user interface 
generator, which communicates with the user via the client's local internet browser. 
( See col. 2, lines 7-12 ). Such a system enables a heterogeneous system to view 
different vendors products. Therefore, claim 2 is rejected. 
10. Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kraslavsky (US 5,699,350) in view of Rune (US 6,304,913), and further in view of Ogus 
(U.S. 6.587,875). 

Referring to claim 5, Kraslavsky teaches the invention substantially as claimed 
including an application according to claim 1 comprising: means for causing said 
IPX/SPX broadcast means to transmit a name request for an IPX/SPX server providing 
a service; and means, responsive to receipt of a response to said name request 
containing an IPX/SPX address of an IPX/SPX server, for relaying said address to said 
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application enabling connection oriented peer-to-peer communication between said 
application and said IPX/SPX server. ( See col. 13, line 1-7: col. 11, lines 11-48 ). 

Kraslavsky teaches means for causing an IPX/SPX broadcast. Kraslavsky does 
not specifically teach transmission of a name request for an IPX/SPX server providing a 
service and peer-to-peer communication. However, Rune teaches a method and 
Internet system that responds to a DNS host request. ( See col. 4, lines 28-37: col. 5, 
lines 27-38 ). Hence, it would have been obvious at the time of the invention for an 
artisan of ordinary skill in the art to combine the communication system taught by 
Kraslavsky with the DNS server disclosed by Rune. Such a system would provide 
efficacy to the network. 

Kraslavsky teaches an application operable on a computer adapted to 
communicate using at least an IPX/SPX protocol. Kraslavsky fails to specifically teach 
receiving RIP response packets from within a specific number of network hops. 
However, Rune teaches this concept extensively. ( See Fig. 4, 5, 7, 8, 9, 10 and col. 4, 
lines 37-43 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the hop count system disclosed by Rune. Such a system would improve efficiency of the 
network. 
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11- Claims 12-19 are rejected under 35 U.S.C. §1 03(a) as being unpatentable over 
Kraslavskv (US 5.699.350) in view of Rune (US 6.304,913.) and in further view of Chen 
et al. (US 6.549.882.) 
Claim 12 : 

A system for simulating a TCP/IP environment in an IPX/SPX network, the system 
comprising: 

a request sender for sending an IPX/SPX Routing Information Protocol (RIP) 
request packet to IPX subnets connected within a specified number of hops; ( See col. 13. 
lines 1-27: col. 14. lines 37-47 .) 

a responses collector for receiving responses to the RIP request packet from the 
IPX subnetys, each response having a response IPX NetNumber and a response number 
of hops; and ( See col. 11, lines 11-48 .) 

a response filter for filtering the responses to remove responses in which the 
response number of hops is greater than the specified number of hops to produce a set of 
network numbers, 

wherein the set of network numbers may be used to send an IPX/SPX packet to a 
subnet included within the set of network numbers. 

The recitation "system for simulating a TCP/IP environment in an IPX/SPX 
network" has not been given patentable weight because the recitation occurs in the 
preamble. A preamble is generally not accorded any patentable weight where it merely 
recites the purpose of a process or the intended use of a structure, and where the body 
of the claim does not depend on the preamble for completeness but, instead, the 
process steps or structural limitations are able to stand alone. See In re Hirao, 535 



Application/Control Number: 09/887,499 Page 16 

Art Unit: 2157 

F.2d 67, 190 USPQ 15 (CCPA 1976) and Kropa v. Robie, 187 F.2d 150, 152, 88 
USPQ 478, 481 (CCPA 1951). 

Kraslavsky teaches an application operable on a computer adapted to 
communicate using at least an IPX/SPX protocol. Kraslavsky fails to specifically teach a 
response from a number of hops. However, Rune teaches this concept extensively. 
( See Fig. 4, 5, 7. 8 f 9, 10 and col. 4, lines 37-43 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the hop count system disclosed by Rune. Such a system would improve efficiency of the 
network. 

Neither Kraslavsky nor Rune teach filter for filtering responses. However, Chen 
extensively discloses a filter. See Fig. 2, Fig. 3A, col. 2, lines 13-19.) 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky and the 
hop count system disclosed by Rune with the filtering process disclosed by Chen. Such a 
system would improve efficiency of the network by discriminating against responses from 
servers that are greater than a predefined number. 
Claim 13 : 

The system of claim 12, wherein the responses filter further stores the set of 
network numbers in a table. 

Kraslavsky teaches an application operable on a computer adapted to communicate 
using at least an IPX/SPX protocol. Kraslavsky fails to specifically teach a response from a 
number of hops. However, Rune teaches this concept extensively and Rune also teaches 
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storing the addresses in a database (i.e. a table.) (See Fig. 4, 5, 7, 8, 9, 10; col. 4, lines 
37-43 and col. 10, lines 25-27 .) 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the hop count system disclosed by Rune. Such a system would improve efficiency of the 
network. 

Neither Kraslavsky nor Rune teach a filter storing the numbers in a table. However, 
Chen extensively discloses a filter taking actions if some conditions are met. (See col. 4, 
line 64-col. 5, line 6.) 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky and the 
hop count system disclosed by Rune with the filtering process disclosed by Chen. Such a 
system would improve efficiency in that reference can be readily made to the table rather 
than repeating the same steps if and when the same conditions are encountered. 
Claim 14 : 

The system of claim 13, wherein the table of network numbers may be accessed to 
locate a server located on an IPX/SPX network in the case of a failure to locate a 
corresponding TCP/IP address for a web server. 

.Kraslavsky teaches means for causing an IPX/SPX broadcast and communication 
using TCP/IP protocol. ( See col. 11, lines 11-26: col. 13, lines 1-6, 28-50 ). Kraslavsky 
does not specifically disclose response to a domain name server (DNS) response 
indicating failure to locate a web server corresponding to a uniform resource locator (URL). 
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However, Rune specifically discloses a DNS server failing to locate a host. (See col. 5. 
lines 27-56 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the DNS server disclosed by Rune. Such a system would provide efficacy to the 
network. 
Claim 15 : 

The system of claim 12, further comprising an IPX/SPX broadcast module for 
broadcasting the IPX/SPX packet to a selected subnet. (See col. 14, lines 58-61 .) Hence, 
it would have been obvious at the time of the invention for an artisan of ordinary skill in the 
art to use the communication system taught by Kraslavsky. 
Claim 16 : 

The system of claim 15, wherein the IPX/SPX broadcast module uses a broadcast 
number of hops to indicate the selected subnet. 

Kraslavsky teaches an IPX/SPX broadcast module adapted to obtain RARP's 
address of the nearest server. Kraslavsky fails to specifically teach number of hops 
indicating the selected subnet. However, Rune teaches this concept extensively. (See 
Fig. 4. 5. 7. 8. 9. 10 and col. 4. lines 37-43 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combinethe communication system taught by Kraslavsky with 
the hop count system disclosed by Rune. Such a system would improve efficiency of the 
network. 
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Claim 17 : 

The system of claim 12, wherein the request sender sends the IPX/SPX Routing 
Information Packet in response to the sending of the IPX/SPX packet having a sending 
number of hops that is greater than the specified number of hops. 

Kraslavsky teaches an application operable on a computer adapted to communicate 
using at least an IPX/SPX protocol. Kraslavsky fails to specifically teach a packet having a 
sending number of hops. However, Rune teaches this concept extensively and Rune also 
teaches storing the addresses in a database (i.e. a table.) ( See Fig. 4, 5, 7, 8. 9, 10: col. 4. 
lines 37-43 and col. 10, lines 25-27 .) 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the hop count system disclosed by Rune. Such a system would improve efficiency of the 
network. 

Neither Kraslavsky nor Rune teach a filter taking actions if some conditions are met. 
However, Chen extensively discloses a filter taking actions if some conditions are met. 
(See col. 4, line 64-col. 5, line 6.) 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky and the 
hop count system disclosed by Rune with the filtering process disclosed by Chen. Such a 
system would improve efficiency in that reference can be readily made to the table rather 
than repeating the same steps if and when the same conditions are encountered. 
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Claim 18 : 

The system of claim 12, wherein the request sender sends the IPX/SPX Routing 
Information Packet in response to a DNS response indicating a failure to locate a TCP/IP 
address for a requested web server. 

Kraslavsky teaches means for causing an IPX/SPX broadcast and 
communication using TCP/IP protocol. ( See col. 11, lines 11-26: col. 13, lines 1-6. 28- 
50 ). Kraslavsky does not specifically disclose response to a domain name server (DNS) 
response indicating failure to locate a web server corresponding to a uniform resource 
locator (URL). However, Rune specifically discloses a DNS server failing to locate a 
host. ( See col. 5, lines 27-56 ). 

Hence, it would have been obvious at the time of the invention for an artisan of 
ordinary skill in the art to combine the communication system taught by Kraslavsky with 
the DNS server disclosed by Rune. Such a system would provide efficacy to the 
network. 
Claim 19 : 

The system of claim 12, wherein the request sender periodically sends the IPX/SPX 
Routing Information Packet according to a pre-defined schedule. 

This claim is objected to for depending upon a rejected claim. 
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Conclusion 

12. THIS ACTION IS MADE FINAL 

Applicant's addition of new claims (amendment) necessitated the new ground(s) 
of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE 
FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy 
as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

13. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Emmanuel Coffy whose telephone number is (571) 272- 
3997. The examiner can normally be reached on 8:30 - 5:00 P.M. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ario Etienne can be reached on (571) 272-4001. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 
Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
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applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 



Emmanuel Coffy 
Patent Examiner 
Art Unit 21 57 
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